Open Bug 1478096 Opened 7 years ago Updated 3 years ago

Windows ASan Nightly Setup "maintenanceservice_tmp.exe - System Error"

Categories

(Firefox :: Installer, defect, P3)

x86_64
Windows
defect

Tracking

()

Tracking Status
firefox63 --- affected

People

(Reporter: decoder, Unassigned)

References

(Blocks 1 open bug)

Details

Original reporter is Dave (Cc'ed) and I confirmed this: When you run the installer for the ASan Nightly builds, the following error pops up: > Title: maintenanceservice_tmp.exe - System Error > > Body: [red circle with white X icon] The program can't start because clang_rt.asan_dynamic-x86-64.dll is missing from your computer. Try reinstalling the program to fix this problem. After the error, the installation continues normally. I assume the updater service isn't installed properly in this case?
decoder, is the reporting machinery able to catch ASan complaints in binaries other than firefox.exe? If not, maybe we should be compiling those without -fsanitize=address, as it's greater risk of bad user experience than the value we get from it. In fact, for "critical to ensuring a usable installation" things like maintenanceservice.exe and updater.exe, maybe we should avoid ASan regardless.
(In reply to David Major [:dmajor] from comment #1) > decoder, is the reporting machinery able to catch ASan complaints in > binaries other than firefox.exe? Yes, if the binary sets the log_path to the correct value, e.g. like here: https://searchfox.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#5314 which is called with the profile directory. I assume the isn't possible if that executable doesn't know the profile path. > > In fact, for "critical to ensuring a usable installation" things like > maintenanceservice.exe and updater.exe, maybe we should avoid ASan > regardless. I agree and I don't think we can report errors in these two easily anyway.
> > In fact, for "critical to ensuring a usable installation" things like > > maintenanceservice.exe and updater.exe, maybe we should avoid ASan > > regardless. > > I agree and I don't think we can report errors in these two easily anyway. glandium -- any advice on how to approach this from the build system side? Should we do some sort of targeted filter-out on CFLAGS in certain directories like maintenanceservice? (Is that too brittle?)
Flags: needinfo?(mh+mozilla)
Sounds like something like what we do for VISIBILITY or STL would be in order. Chris, thoughts?
Flags: needinfo?(mh+mozilla) → needinfo?(cmanchester)
To turn off ASAN in certain directories? Yes a template like one of those would be fine. Probably the best way would be to put sanitizer flags in their own category and zero that out where necessary (as with `DisableStlWrapping`).
Flags: needinfo?(cmanchester)
decoder, want to take a stab at this?
Priority: -- → P3

With bug 1649557 now being fixed (and it didn't fix this) I'm guessing the fix to this is probably something similar but in a different build file.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.